Design rule checking (DRC) is used in electronic design automation (EDA) of integrated circuits to determine whether the physical layout of a particular chip design satisfies a series of recommended parameters called design rules. Design rules are a series of parameters provided by semiconductor manufacturers that enable the designer to verify the correctness of a mask set. Design rules are specific to a particular semiconductor manufacturing process. A design rule set specifies certain geometric and connectivity restrictions to ensure sufficient margins to account for variability in semiconductor manufacturing processes, so as to ensure that most of the parts work correctly.
Specific design rule checks verify the shape and sizes of various circuit components that are diffused, deposited, or etched onto a chip. Additionally, design rule checking also verifies that the shapes are of the proper size, shape, and type, and furthermore, that the shapes are not placed so close together within the chip that they will not work. Design rule checking may involve a general purpose shapes processing program (GPSPP) that receives inputs from two files: runset and physical layout files. The runset file is a command language input file that instructs the processor executing the GPSPP how to perform the design rule checks. The runset may include several hundred individual design rule checks, for example. The runset may also be referred to as a DRC runset, a rule deck, or merely a deck.
Design rules (also referred to as DRC rules) specify how the layers in the layout should be arranged to ensure good manufacturing yield in a foundry. The runset is provided by the foundry and is coded based on a design manual. Inputs from the technology development and manufacturing teams, and information on the devices supported in a particular technology, are used by the design manual team to create the DRC rules in the design manual. It is thus advantageous to ensure that the runset is consistent with the design manual since customers are expected to ensure their designs are “DRC clean” on this “golden” runset.
When developing a runset for a semiconductor process, a set of layout test cases is used to verify functionality and accuracy. The task of creating test cases for runsets exists across all organizations and companies that code checking runsets. The code for DRC is created based on a set of layout design rules or parameters for a particular semiconductor process. The code and test cases are both manually created.
A runset may be validated with regression testing that uses shape-based test cases that are based on rules described in the design manual. For example, regression testing involves creating such test cases and verifying the test cases against the runset. The test cases used in regression testing are not based on an actual circuit design, but rather are simple shapes based on rules included in the design manual and designed to trigger either a pass condition or a fail condition when verified against the runset. Both pass test cases and fail test cases are built to ensure good verification coverage of the design rules. For example, the fail test cases are designed to cause the runset to report an error, and the pass test cases are designed such that the runset should not report an error. In the event the runset does not behave as expected according to the test cases, then one or more design rule checks in the runset may be modified, or the design manual itself may be modified, or both.
Since the test cases used in regression testing are manually created, they are necessarily limited by the imagination and/or expertise of the person tasked with creating the test cases. This person-based limitation can limit the verification coverage provided by the test cases. The verification coverage is also limited since the number of ways in which a rule can be violated grows exponentially with the number of layers/constraints involved in the rule. As the number of layers and constraints in a design increases, it becomes unworkable to manually create test cases that provide sufficient verification coverage.